SGI Freeware 1999 August

home *** CD-ROM | disk | FTP | other *** search

/ SGI Freeware 1999 August / SGI Freeware 1999 August.iso / dist / fw_tcpdump.idb / usr / freeware / catman / u_man / cat1 / tcpdump.Z / tcpdump

Wrap

Text File | 1999-04-16 | 60.6 KB | 1,255 lines

TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) NNNNAAAAMMMMEEEE tcpdump - dump traffic on a network SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS ttttccccppppdddduuuummmmpppp [ ----aaaaddddeeeeffffllllnnnnNNNNOOOOppppqqqqSSSSttttvvvvxxxx ] [ ----cccc _c_o_u_n_t ] [ ----FFFF _f_i_l_e ] [ ----iiii _i_n_t_e_r_f_a_c_e ] [ ----rrrr _f_i_l_e ] [ ----ssss _s_n_a_p_l_e_n ] [ ----TTTT _t_y_p_e ] [ ----wwww _f_i_l_e ] [ _e_x_p_r_e_s_s_i_o_n ] DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _T_c_p_d_u_m_p prints out the headers of packets on a network interface that match the boolean _e_x_p_r_e_s_s_i_o_n. UUUUnnnnddddeeeerrrr SSSSuuuunnnnOOOOSSSS wwwwiiiitttthhhh nnnniiiitttt oooorrrr bbbbppppffff:::: To run _t_c_p_d_u_m_p you must have read access to /_d_e_v/_n_i_t or /_d_e_v/_b_p_f*. UUUUnnnnddddeeeerrrr SSSSoooollllaaaarrrriiiissss wwwwiiiitttthhhh ddddllllppppiiii:::: You must have read access to the network pseudo device, e.g. /_d_e_v/_l_e. UUUUnnnnddddeeeerrrr HHHHPPPP----UUUUXXXX wwwwiiiitttthhhh ddddllllppppiiii:::: You must be root or it must be installed setuid to root. UUUUnnnnddddeeeerrrr IIIIRRRRIIIIXXXX wwwwiiiitttthhhh ssssnnnnoooooooopppp:::: You must be root or it must be installed setuid to root. UUUUnnnnddddeeeerrrr LLLLiiiinnnnuuuuxxxx:::: You must be root or it must be installed setuid to root. UUUUnnnnddddeeeerrrr UUUUllllttttrrrriiiixxxx aaaannnndddd DDDDiiiiggggiiiittttaaaallll UUUUNNNNIIIIXXXX:::: Once the super-user has enabled promiscuous-mode operation using _p_f_c_o_n_f_i_g(8), any user may run ttttccccppppdddduuuummmmpppp. UUUUnnnnddddeeeerrrr BBBBSSSSDDDD:::: You must have read access to /_d_e_v/_b_p_f*. OOOOPPPPTTTTIIIIOOOONNNNSSSS ----aaaa Attempt to convert network and broadcast addresses to names. ----cccc Exit after receiving _c_o_u_n_t packets. ----dddd Dump the compiled packet-matching code in a human readable form to standard output and stop. ----dddddddd Dump packet-matching code as a CCCC program fragment. ----dddddddddddd Dump packet-matching code as decimal numbers (preceded with a count). ----eeee Print the link-level header on each dump line. ----ffff Print `foreign' internet addresses numerically rather than symbolically (this option is intended to get around serious brain damage in Sun's yp server - usually it hangs forever translating non-local internet numbers). ----FFFF Use _f_i_l_e as input for the filter expression. An additional expression given on the command line is ignored. ----iiii Listen on _i_n_t_e_r_f_a_c_e. If unspecified, _t_c_p_d_u_m_p searches the system interface list for the lowest numbered, Page 1 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) configured up interface (excluding loopback). Ties are broken by choosing the earliest match. ----llll Make stdout line buffered. Useful if you want to see the data while capturing it. E.g., ``tcpdump -l | tee dat'' or ``tcpdump -l > dat & tail -f dat''. ----nnnn Don't convert addresses (i.e., host addresses, port numbers, etc.) to names. ----NNNN Don't print domain name qualification of host names. E.g., if you give this flag then _t_c_p_d_u_m_p will print ``nic'' instead of ``nic.ddn.mil''. ----OOOO Do not run the packet-matching code optimizer. This is useful only if you suspect a bug in the optimizer. ----pppp _D_o_n'_t put the interface into promiscuous mode. Note that the interface might be in promiscuous mode for some other reason; hence, `-p' cannot be used as an abbreviation for `ether host {local-hw-addr} or ether broadcast'. ----qqqq Quick (quiet?) output. Print less protocol information so output lines are shorter. ----rrrr Read packets from _f_i_l_e (which was created with the -w option). Standard input is used if _f_i_l_e is ``-''. ----ssss Snarf _s_n_a_p_l_e_n bytes of data from each packet rather than the default of 68 (with SunOS's NIT, the minimum is actually 96). 68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate protocol information from name server and NFS packets (see below). Packets truncated because of a limited snapshot are indicated in the output with ``[|_p_r_o_t_o]'', where _p_r_o_t_o is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit _s_n_a_p_l_e_n to the smallest number that will capture the protocol information you're interested in. ----TTTT Force packets selected by "_e_x_p_r_e_s_s_i_o_n" to be interpreted the specified _t_y_p_e. Currently known types are rrrrppppcccc (Remote Procedure Call), rrrrttttpppp (Real-Time Applications protocol), rrrrttttccccpppp (Real-Time Applications control protocol), vvvvaaaatttt (Visual Audio Tool), and wwwwbbbb (distributed White Board). Page 2 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) ----SSSS Print absolute, rather than relative, TCP sequence numbers. ----tttt _D_o_n'_t print a timestamp on each dump line. ----tttttttt Print an unformatted timestamp on each dump line. ----vvvv (Slightly more) verbose output. For example, the time to live and type of service information in an IP packet is printed. ----vvvvvvvv Even more verbose output. For example, additional fields are printed from NFS reply packets. ----wwww Write the raw packets to _f_i_l_e rather than parsing and printing them out. They can later be printed with the -r option. Standard output is used if _f_i_l_e is ``-''. ----xxxx Print each packet (minus its link level header) in hex. The smaller of the entire packet or _s_n_a_p_l_e_n bytes will be printed. _e_x_p_r_e_s_s_i_o_n selects which packets will be dumped. If no _e_x_p_r_e_s_s_i_o_n is given, all packets on the net will be dumped. Otherwise, only packets for which _e_x_p_r_e_s_s_i_o_n is `true' will be dumped. The _e_x_p_r_e_s_s_i_o_n consists of one or more _p_r_i_m_i_t_i_v_e_s. Primitives usually consist of an _i_d (name or number) preceded by one or more qualifiers. There are three different kinds of qualifier: _t_y_p_e qualifiers say what kind of thing the id name or number refers to. Possible types are hhhhoooosssstttt, nnnneeeetttt and ppppoooorrrrtttt. E.g., `host foo', `net 128.3', `port 20'. If there is no type qualifier, hhhhoooosssstttt is assumed. _d_i_r qualifiers specify a particular transfer direction to and/or from _i_d. Possible directions are ssssrrrrcccc, ddddsssstttt, ssssrrrrcccc oooorrrr ddddsssstttt and ssssrrrrcccc aaaannnndddd ddddsssstttt. E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'. If there is no dir qualifier, ssssrrrrcccc oooorrrr ddddsssstttt is assumed. For `null' link layers (i.e. point to point protocols such as slip) the iiiinnnnbbbboooouuuunnnndddd and oooouuuuttttbbbboooouuuunnnndddd qualifiers can be used to specify a desired direction. _p_r_o_t_o qualifiers restrict the match to a particular protocol. Possible protos are: eeeetttthhhheeeerrrr, ffffddddddddiiii, iiiipppp, Page 3 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) aaaarrrrpppp, rrrraaaarrrrpppp, ddddeeeeccccnnnneeeetttt, llllaaaatttt, ssssccccaaaa, mmmmoooopppprrrrcccc, mmmmooooppppddddllll, ttttccccpppp and uuuuddddpppp. E.g., `ether src foo', `arp net 128.3', `tcp port 21'. If there is no proto qualifier, all protocols consistent with the type are assumed. E.g., `src foo' means `(ip or arp or rarp) src foo' (except the latter is not legal syntax), `net bar' means `(ip or arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'. [`fddi' is actually an alias for `ether'; the parser treats them identically as meaning ``the data link level used on the specified network interface.'' FDDI headers contain Ethernet-like source and destination addresses, and often contain Ethernet-like packet types, so you can filter on these FDDI fields just as with the analogous Ethernet fields. FDDI headers also contain other fields, but you cannot name them explicitly in a filter expression.] In addition to the above, there are some special `primitive' keywords that don't follow the pattern: ggggaaaatttteeeewwwwaaaayyyy, bbbbrrrrooooaaaaddddccccaaaasssstttt, lllleeeessssssss, ggggrrrreeeeaaaatttteeeerrrr and arithmetic expressions. All of these are described below. More complex filter expressions are built up by using the words aaaannnndddd, oooorrrr and nnnnooootttt to combine primitives. E.g., `host foo and not port ftp and not port ftp-data'. To save typing, identical qualifier lists can be omitted. E.g., `tcp dst port ftp or ftp-data or domain' is exactly the same as `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'. Allowable primitives are: ddddsssstttt hhhhoooosssstttt _h_o_s_t True if the IP destination field of the packet is _h_o_s_t, which may be either an address or a name. ssssrrrrcccc hhhhoooosssstttt _h_o_s_t True if the IP source field of the packet is _h_o_s_t. hhhhoooosssstttt _h_o_s_t True if either the IP source or destination of the packet is _h_o_s_t. Any of the above host expressions can be prepended with the keywords, iiiipppp, aaaarrrrpppp, or rrrraaaarrrrpppp as in: iiiipppp hhhhoooosssstttt _h_o_s_t which is equivalent to: eeeetttthhhheeeerrrr pppprrrroooottttoooo \_i_p aaaannnndddd hhhhoooosssstttt _h_o_s_t If _h_o_s_t is a name with multiple IP addresses, each address will be checked for a match. Page 4 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) eeeetttthhhheeeerrrr ddddsssstttt _e_h_o_s_t True if the ethernet destination address is _e_h_o_s_t. _E_h_o_s_t may be either a name from /etc/ethers or a number (see _e_t_h_e_r_s(3N) for numeric format). eeeetttthhhheeeerrrr ssssrrrrcccc _e_h_o_s_t True if the ethernet source address is _e_h_o_s_t. eeeetttthhhheeeerrrr hhhhoooosssstttt _e_h_o_s_t True if either the ethernet source or destination address is _e_h_o_s_t. ggggaaaatttteeeewwwwaaaayyyy _h_o_s_t True if the packet used _h_o_s_t as a gateway. I.e., the ethernet source or destination address was _h_o_s_t but neither the IP source nor the IP destination was _h_o_s_t. _H_o_s_t must be a name and must be found in both /etc/hosts and /etc/ethers. (An equivalent expression is eeeetttthhhheeeerrrr hhhhoooosssstttt _e_h_o_s_t aaaannnndddd nnnnooootttt hhhhoooosssstttt _h_o_s_t which can be used with either names or numbers for _h_o_s_t / _e_h_o_s_t.) ddddsssstttt nnnneeeetttt _n_e_t True if the IP destination address of the packet has a network number of _n_e_t. _N_e_t may be either a name from /etc/networks or a network number (see _n_e_t_w_o_r_k_s(_4) for details). ssssrrrrcccc nnnneeeetttt _n_e_t True if the IP source address of the packet has a network number of _n_e_t. nnnneeeetttt _n_e_t True if either the IP source or destination address of the packet has a network number of _n_e_t. nnnneeeetttt _n_e_t mmmmaaaasssskkkk _m_a_s_k True if the IP address matches _n_e_t with the specific netmask. May be qualified with ssssrrrrcccc or ddddsssstttt. nnnneeeetttt _n_e_t/_l_e_n True if the IP address matches _n_e_t a netmask _l_e_n bits wide. May be qualified with ssssrrrrcccc or ddddsssstttt. ddddsssstttt ppppoooorrrrtttt _p_o_r_t True if the packet is ip/tcp or ip/udp and has a destination port value of _p_o_r_t. The _p_o_r_t can be a number or a name used in /etc/services (see _t_c_p(4P) and _u_d_p(4P)). If a name is used, both the port number and protocol are checked. If a number Page 5 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) or ambiguous name is used, only the port number is checked (e.g., ddddsssstttt ppppoooorrrrtttt 555511113333 will print both tcp/login traffic and udp/who traffic, and ppppoooorrrrtttt ddddoooommmmaaaaiiiinnnn will print both tcp/domain and udp/domain traffic). ssssrrrrcccc ppppoooorrrrtttt _p_o_r_t True if the packet has a source port value of _p_o_r_t. ppppoooorrrrtttt _p_o_r_t True if either the source or destination port of the packet is _p_o_r_t. Any of the above port expressions can be prepended with the keywords, ttttccccpppp or uuuuddddpppp, as in: ttttccccpppp ssssrrrrcccc ppppoooorrrrtttt _p_o_r_t which matches only tcp packets whose source port is _p_o_r_t. lllleeeessssssss _l_e_n_g_t_h True if the packet has a length less than or equal to _l_e_n_g_t_h. This is equivalent to: lllleeeennnn <<<<==== _l_e_n_g_t_h.... ggggrrrreeeeaaaatttteeeerrrr _l_e_n_g_t_h True if the packet has a length greater than or equal to _l_e_n_g_t_h. This is equivalent to: lllleeeennnn >>>>==== _l_e_n_g_t_h.... iiiipppp pppprrrroooottttoooo _p_r_o_t_o_c_o_l True if the packet is an ip packet (see _i_p(4P)) of protocol type _p_r_o_t_o_c_o_l. _P_r_o_t_o_c_o_l can be a number or one of the names _i_c_m_p, _i_g_r_p, _u_d_p, _n_d, or _t_c_p. Note that the identifiers _t_c_p, _u_d_p, and _i_c_m_p are also keywords and must be escaped via backslash (\), which is \\ in the C-shell. eeeetttthhhheeeerrrr bbbbrrrrooooaaaaddddccccaaaasssstttt True if the packet is an ethernet broadcast packet. The _e_t_h_e_r keyword is optional. iiiipppp bbbbrrrrooooaaaaddddccccaaaasssstttt True if the packet is an IP broadcast packet. It checks for both the all-zeroes and all-ones broadcast conventions, and looks up the local subnet mask. eeeetttthhhheeeerrrr mmmmuuuullllttttiiiiccccaaaasssstttt True if the packet is an ethernet multicast packet. The _e_t_h_e_r keyword is optional. This is shorthand for `eeeetttthhhheeeerrrr[[[[0000]]]] &&&& 1111 !!!!==== 0000'. Page 6 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) iiiipppp mmmmuuuullllttttiiiiccccaaaasssstttt True if the packet is an IP multicast packet. eeeetttthhhheeeerrrr pppprrrroooottttoooo _p_r_o_t_o_c_o_l True if the packet is of ether type _p_r_o_t_o_c_o_l. _P_r_o_t_o_c_o_l can be a number or a name like _i_p, _a_r_p, or _r_a_r_p. Note these identifiers are also keywords and must be escaped via backslash (\). [In the case of FDDI (e.g., `ffffddddddddiiii pppprrrroooottttooooccccoooollll aaaarrrrpppp'), the protocol identification comes from the 802.2 Logical Link Control (LLC) header, which is usually layered on top of the FDDI header. _T_c_p_d_u_m_p assumes, when filtering on the protocol identifier, that all FDDI packets include an LLC header, and that the LLC header is in so-called SNAP format.] ddddeeeeccccnnnneeeetttt ssssrrrrcccc _h_o_s_t True if the DECNET source address is _h_o_s_t, which may be an address of the form ``10.123'', or a DECNET host name. [DECNET host name support is only available on Ultrix systems that are configured to run DECNET.] ddddeeeeccccnnnneeeetttt ddddsssstttt _h_o_s_t True if the DECNET destination address is _h_o_s_t. ddddeeeeccccnnnneeeetttt hhhhoooosssstttt _h_o_s_t True if either the DECNET source or destination address is _h_o_s_t. iiiipppp, aaaarrrrpppp, rrrraaaarrrrpppp, ddddeeeeccccnnnneeeetttt Abbreviations for: eeeetttthhhheeeerrrr pppprrrroooottttoooo _p where _p is one of the above protocols. llllaaaatttt, mmmmoooopppprrrrcccc, mmmmooooppppddddllll Abbreviations for: eeeetttthhhheeeerrrr pppprrrroooottttoooo _p where _p is one of the above protocols. Note that _t_c_p_d_u_m_p does not currently know how to parse these protocols. ttttccccpppp, uuuuddddpppp, iiiiccccmmmmpppp Abbreviations for: iiiipppp pppprrrroooottttoooo _p where _p is one of the above protocols. _e_x_p_r _r_e_l_o_p _e_x_p_r True if the relation holds, where _r_e_l_o_p is one of >, <, >=, <=, =, !=, and _e_x_p_r is an arithmetic expression composed of integer constants Page 7 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) (expressed in standard C syntax), the normal binary operators [+, -, *, /, &, |], a length operator, and special packet data accessors. To access data inside the packet, use the following syntax: _p_r_o_t_o [[[[ _e_x_p_r :::: _s_i_z_e ]]]] _P_r_o_t_o is one of eeeetttthhhheeeerrrr,,,, ffffddddddddiiii,,,, iiiipppp,,,, aaaarrrrpppp,,,, rrrraaaarrrrpppp,,,, ttttccccpppp,,,, uuuuddddpppp,,,, or iiiiccccmmmmpppp, and indicates the protocol layer for the index operation. The byte offset, relative to the indicated protocol layer, is given by _e_x_p_r. _S_i_z_e is optional and indicates the number of bytes in the field of interest; it can be either one, two, or four, and defaults to one. The length operator, indicated by the keyword lllleeeennnn, gives the length of the packet. For example, `eeeetttthhhheeeerrrr[[[[0000]]]] &&&& 1111 !!!!==== 0000' catches all multicast traffic. The expression `iiiipppp[[[[0000]]]] &&&& 0000xxxxffff !!!!==== 5555' catches all IP packets with options. The expression `iiiipppp[[[[6666::::2222]]]] &&&& 0000xxxx1111ffffffffffff ==== 0000' catches only unfragmented datagrams and frag zero of fragmented datagrams. This check is implicitly applied to the ttttccccpppp and uuuuddddpppp index operations. For instance, ttttccccpppp[[[[0000]]]] always means the first byte of the TCP _h_e_a_d_e_r, and never means the first byte of an intervening fragment. Primitives may be combined using: A parenthesized group of primitives and operators (parentheses are special to the Shell and must be escaped). Negation (`!!!!' or `nnnnooootttt'). Concatenation (`&&&&&&&&' or `aaaannnndddd'). Alternation (`||||||||' or `oooorrrr'). Negation has highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit aaaannnndddd tokens, not juxtaposition, are now required for concatenation. If an identifier is given without a keyword, the most recent keyword is assumed. For example, nnnnooootttt hhhhoooosssstttt vvvvssss aaaannnndddd aaaacccceeee is short for nnnnooootttt hhhhoooosssstttt vvvvssss aaaannnndddd hhhhoooosssstttt aaaacccceeee which should not be confused with nnnnooootttt (((( hhhhoooosssstttt vvvvssss oooorrrr aaaacccceeee )))) Page 8 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) Expression arguments can be passed to tcpdump as either a single argument or as multiple arguments, whichever is more convenient. Generally, if the expression contains Shell metacharacters, it is easier to pass it as a single, quoted argument. Multiple arguments are concatenated with spaces before being parsed. EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS To print all packets arriving at or departing from _s_u_n_d_o_w_n: ttttccccppppdddduuuummmmpppp hhhhoooosssstttt ssssuuuunnnnddddoooowwwwnnnn To print traffic between _h_e_l_i_o_s and either _h_o_t or _a_c_e: ttttccccppppdddduuuummmmpppp hhhhoooosssstttt hhhheeeelllliiiioooossss aaaannnndddd \\\\(((( hhhhooootttt oooorrrr aaaacccceeee \\\\)))) To print all IP packets between _a_c_e and any host except _h_e_l_i_o_s: ttttccccppppdddduuuummmmpppp iiiipppp hhhhoooosssstttt aaaacccceeee aaaannnndddd nnnnooootttt hhhheeeelllliiiioooossss To print all traffic between local hosts and hosts at Berkeley: ttttccccppppdddduuuummmmpppp nnnneeeetttt uuuuccccbbbb----eeeetttthhhheeeerrrr To print all ftp traffic through internet gateway _s_n_u_p: (note that the expression is quoted to prevent the shell from (mis-)interpreting the parentheses): ttttccccppppdddduuuummmmpppp ''''ggggaaaatttteeeewwwwaaaayyyy ssssnnnnuuuupppp aaaannnndddd ((((ppppoooorrrrtttt ffffttttpppp oooorrrr ffffttttpppp----ddddaaaattttaaaa))))'''' To print traffic neither sourced from nor destined for local hosts (if you gateway to one other net, this stuff should never make it onto your local net). ttttccccppppdddduuuummmmpppp iiiipppp aaaannnndddd nnnnooootttt nnnneeeetttt _l_o_c_a_l_n_e_t To print the start and end packets (the SYN and FIN packets) of each TCP conversation that involves a non-local host. ttttccccppppdddduuuummmmpppp ''''ttttccccpppp[[[[11113333]]]] &&&& 3333 !!!!==== 0000 aaaannnndddd nnnnooootttt ssssrrrrcccc aaaannnndddd ddddsssstttt nnnneeeetttt _l_o_c_a_l_n_e_t'''' To print IP packets longer than 576 bytes sent through gateway _s_n_u_p: ttttccccppppdddduuuummmmpppp ''''ggggaaaatttteeeewwwwaaaayyyy ssssnnnnuuuupppp aaaannnndddd iiiipppp[[[[2222::::2222]]]] >>>> 555577776666'''' To print IP broadcast or multicast packets that were _n_o_t sent via ethernet broadcast or multicast: ttttccccppppdddduuuummmmpppp ''''eeeetttthhhheeeerrrr[[[[0000]]]] &&&& 1111 ==== 0000 aaaannnndddd iiiipppp[[[[11116666]]]] >>>>==== 222222224444'''' To print all ICMP packets that are not echo requests/replies (i.e., not ping packets): ttttccccppppdddduuuummmmpppp ''''iiiiccccmmmmpppp[[[[0000]]]] !!!!==== 8888 aaaannnndddd iiiiccccmmmmpppp[[[[0000]]]] !!!!==== 0000"""" OOOOUUUUTTTTPPPPUUUUTTTT FFFFOOOORRRRMMMMAAAATTTT The output of _t_c_p_d_u_m_p is protocol dependent. The following gives a brief description and examples of most of the formats. Page 9 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) LLLLiiiinnnnkkkk LLLLeeeevvvveeeellll HHHHeeeeaaaaddddeeeerrrrssss If the '-e' option is given, the link level header is printed out. On ethernets, the source and destination addresses, protocol, and packet length are printed. On FDDI networks, the '-e' option causes _t_c_p_d_u_m_p to print the `frame control' field, the source and destination addresses, and the packet length. (The `frame control' field governs the interpretation of the rest of the packet. Normal packets (such as those containing IP datagrams) are `async' packets, with a priority value between 0 and 7; for example, `aaaassssyyyynnnncccc4444'. Such packets are assumed to contain an 802.2 Logical Link Control (LLC) packet; the LLC header is printed if it is _n_o_t an ISO datagram or a so-called SNAP packet. (_N._B.: _T_h_e _f_o_l_l_o_w_i_n_g _d_e_s_c_r_i_p_t_i_o_n _a_s_s_u_m_e_s _f_a_m_i_l_i_a_r_i_t_y _w_i_t_h _t_h_e _S_L_I_P _c_o_m_p_r_e_s_s_i_o_n _a_l_g_o_r_i_t_h_m _d_e_s_c_r_i_b_e_d _i_n _R_F_C-_1_1_4_4.) On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound), packet type, and compression information are printed out. The packet type is printed first. The three types are _i_p, _u_t_c_p, and _c_t_c_p. No further link information is printed for _i_p packets. For TCP packets, the connection identifier is printed following the type. If the packet is compressed, its encoded header is printed out. The special cases are printed out as ****SSSS++++_n and ****SSSSAAAA++++_n, where _n is the amount by which the sequence number (or sequence number and ack) has changed. If it is not a special case, zero or more changes are printed. A change is indicated by U (urgent pointer), W (window), A (ack), S (sequence number), and I (packet ID), followed by a delta (+n or -n), or a new value (=n). Finally, the amount of data in the packet and compressed header length are printed. For example, the following line shows an outbound compressed TCP packet, with an implicit connection identifier; the ack has changed by 6, the sequence number by 49, and the packet ID by 6; there are 3 bytes of data and 6 bytes of compressed header: OOOO ccccttttccccpppp **** AAAA++++6666 SSSS++++44449999 IIII++++6666 3333 ((((6666)))) AAAARRRRPPPP////RRRRAAAARRRRPPPP PPPPaaaacccckkkkeeeettttssss Arp/rarp output shows the type of request and its arguments. The format is intended to be self explanatory. Here is a short sample taken from the start of an `rlogin' from host _r_t_s_g to host _c_s_a_m: arp who-has csam tell rtsg arp reply csam is-at CSAM Page 10 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) The first line says that rtsg sent an arp packet asking for the ethernet address of internet host csam. Csam replies with its ethernet address (in this example, ethernet addresses are in caps and internet addresses in lower case). This would look less redundant if we had done ttttccccppppdddduuuummmmpppp ----nnnn: arp who-has 128.3.254.6 tell 128.3.254.68 arp reply 128.3.254.6 is-at 02:07:01:00:01:c4 If we had done ttttccccppppdddduuuummmmpppp ----eeee, the fact that the first packet is broadcast and the second is point-to-point would be visible: RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM RTSG 0806 64: arp reply csam is-at CSAM For the first packet this says the ethernet source address is RTSG, the destination is the ethernet broadcast address, the type field contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes. TTTTCCCCPPPP PPPPaaaacccckkkkeeeettttssss (_N._B.:_T_h_e _f_o_l_l_o_w_i_n_g _d_e_s_c_r_i_p_t_i_o_n _a_s_s_u_m_e_s _f_a_m_i_l_i_a_r_i_t_y _w_i_t_h _t_h_e _T_C_P _p_r_o_t_o_c_o_l _d_e_s_c_r_i_b_e_d _i_n _R_F_C-_7_9_3. _I_f _y_o_u _a_r_e _n_o_t _f_a_m_i_l_i_a_r _w_i_t_h _t_h_e _p_r_o_t_o_c_o_l, _n_e_i_t_h_e_r _t_h_i_s _d_e_s_c_r_i_p_t_i_o_n _n_o_r _t_c_p_d_u_m_p _w_i_l_l _b_e _o_f _m_u_c_h _u_s_e _t_o _y_o_u.) The general format of a tcp protocol line is: _s_r_c > _d_s_t: _f_l_a_g_s _d_a_t_a-_s_e_q_n_o _a_c_k _w_i_n_d_o_w _u_r_g_e_n_t _o_p_t_i_o_n_s _S_r_c and _d_s_t are the source and destination IP addresses and ports. _F_l_a_g_s are some combination of S (SYN), F (FIN), P (PUSH) or R (RST) or a single `.' (no flags). _D_a_t_a-_s_e_q_n_o describes the portion of sequence space covered by the data in this packet (see example below). _A_c_k is sequence number of the next data expected the other direction on this connection. _W_i_n_d_o_w is the number of bytes of receive buffer space available the other direction on this connection. _U_r_g indicates there is `urgent' data in the packet. _O_p_t_i_o_n_s are tcp options enclosed in angle brackets (e.g., <mss 1024>). _S_r_c, _d_s_t and _f_l_a_g_s are always present. The other fields depend on the contents of the packet's tcp protocol header and are output only if appropriate. Here is the opening portion of an rlogin from host _r_t_s_g to host _c_s_a_m. rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024> csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024> rtsg.1023 > csam.login: . ack 1 win 4096 rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096 csam.login > rtsg.1023: . ack 2 win 4096 Page 11 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096 csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077 csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1 csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1 The first line says that tcp port 1023 on rtsg sent a packet to port _l_o_g_i_n on csam. The SSSS indicates that the _S_Y_N flag was set. The packet sequence number was 768512 and it contained no data. (The notation is `first:last(nbytes)' which means `sequence numbers _f_i_r_s_t up to but not including _l_a_s_t which is _n_b_y_t_e_s bytes of user data'.) There was no piggy-backed ack, the available receive window was 4096 bytes and there was a max-segment-size option requesting an mss of 1024 bytes. Csam replies with a similar packet except it includes a piggy-backed ack for rtsg's SYN. Rtsg then acks csam's SYN. The `.' means no flags were set. The packet contained no data so there is no data sequence number. Note that the ack sequence number is a small integer (1). The first time ttttccccppppdddduuuummmmpppp sees a tcp `conversation', it prints the sequence number from the packet. On subsequent packets of the conversation, the difference between the current packet's sequence number and this initial sequence number is printed. This means that sequence numbers after the first can be interpreted as relative byte positions in the conversation's data stream (with the first data byte each direction being `1'). `-S' will override this feature, causing the original sequence numbers to be output. On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 in the rtsg -> csam side of the conversation). The PUSH flag is set in the packet. On the 7th line, csam says it's received data sent by rtsg up to but not including byte 21. Most of this data is apparently sitting in the socket buffer since csam's receive window has gotten 19 bytes smaller. Csam also sends one byte of data to rtsg in this packet. On the 8th and 9th lines, csam sends two bytes of urgent, pushed data to rtsg. If the snapshot was small enough that ttttccccppppdddduuuummmmpppp didn't capture the full TCP header, it interprets as much of the header as it can and then reports ``[|_t_c_p]'' to indicate the remainder could not be interpreted. If the header contains a bogus option (one with a length that's either too small or beyond the end of the header), tcpdump reports it as ``[_b_a_d _o_p_t]'' and does not interpret any further options (since it's impossible to tell where they start). If the header length indicates options are present but the IP datagram length is not long enough for the options to actually be there, tcpdump reports it as ``[_b_a_d _h_d_r _l_e_n_g_t_h]''. Page 12 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUDDDDPPPP PPPPaaaacccckkkkeeeettttssss UDP format is illustrated by this rwho packet: actinide.who > broadcast.who: udp 84 This says that port _w_h_o on host _a_c_t_i_n_i_d_e sent a udp datagram to port _w_h_o on host _b_r_o_a_d_c_a_s_t, the Internet broadcast address. The packet contained 84 bytes of user data. Some UDP services are recognized (from the source or destination port number) and the higher level protocol information printed. In particular, Domain Name service requests (RFC-1034/1035) and Sun RPC calls (RFC-1050) to NFS. UUUUDDDDPPPP NNNNaaaammmmeeee SSSSeeeerrrrvvvveeeerrrr RRRReeeeqqqquuuueeeessssttttssss (_N._B.:_T_h_e _f_o_l_l_o_w_i_n_g _d_e_s_c_r_i_p_t_i_o_n _a_s_s_u_m_e_s _f_a_m_i_l_i_a_r_i_t_y _w_i_t_h _t_h_e _D_o_m_a_i_n _S_e_r_v_i_c_e _p_r_o_t_o_c_o_l _d_e_s_c_r_i_b_e_d _i_n _R_F_C-_1_0_3_5. _I_f _y_o_u _a_r_e _n_o_t _f_a_m_i_l_i_a_r _w_i_t_h _t_h_e _p_r_o_t_o_c_o_l, _t_h_e _f_o_l_l_o_w_i_n_g _d_e_s_c_r_i_p_t_i_o_n _w_i_l_l _a_p_p_e_a_r _t_o _b_e _w_r_i_t_t_e_n _i_n _g_r_e_e_k.) Name server requests are formatted as _s_r_c > _d_s_t: _i_d _o_p? _f_l_a_g_s _q_t_y_p_e _q_c_l_a_s_s _n_a_m_e (_l_e_n) h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) Host _h_2_o_p_o_l_o asked the domain server on _h_e_l_i_o_s for an address record (qtype=A) associated with the name _u_c_b_v_a_x._b_e_r_k_e_l_e_y._e_d_u. The query id was `3'. The `+' indicates the _r_e_c_u_r_s_i_o_n _d_e_s_i_r_e_d flag was set. The query length was 37 bytes, not including the UDP and IP protocol headers. The query operation was the normal one, _Q_u_e_r_y, so the op field was omitted. If the op had been anything else, it would have been printed between the `3' and the `+'. Similarly, the qclass was the normal one, _C__I_N, and omitted. Any other qclass would have been printed immediately after the `A'. A few anomalies are checked and may result in extra fields enclosed in square brackets: If a query contains an answer, name server or authority section, _a_n_c_o_u_n_t, _n_s_c_o_u_n_t, or _a_r_c_o_u_n_t are printed as `[_na]', `[_nn]' or `[_nau]' where _n is the appropriate count. If any of the response bits are set (AA, RA or rcode) or any of the `must be zero' bits are set in bytes two and three, `[b2&3=_x]' is printed, where _x is the hex value of header bytes two and three. UUUUDDDDPPPP NNNNaaaammmmeeee SSSSeeeerrrrvvvveeeerrrr RRRReeeessssppppoooonnnnsssseeeessss Name server responses are formatted as Page 13 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) _s_r_c > _d_s_t: _i_d _o_p _r_c_o_d_e _f_l_a_g_s _a/_n/_a_u _t_y_p_e _c_l_a_s_s _d_a_t_a (_l_e_n) helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97) In the first example, _h_e_l_i_o_s responds to query id 3 from _h_2_o_p_o_l_o with 3 answer records, 3 name server records and 7 authority records. The first answer record is type A (address) and its data is internet address 128.32.137.3. The total size of the response was 273 bytes, excluding UDP and IP headers. The op (Query) and response code (NoError) were omitted, as was the class (C_IN) of the A record. In the second example, _h_e_l_i_o_s responds to query 2 with a response code of non-existent domain (NXDomain) with no answers, one name server and no authority records. The `*' indicates that the _a_u_t_h_o_r_i_t_a_t_i_v_e _a_n_s_w_e_r bit was set. Since there were no answers, no type, class or data were printed. Other flag characters that might appear are `-' (recursion available, RA, _n_o_t set) and `|' (truncated message, TC, set). If the `question' section doesn't contain exactly one entry, `[_nq]' is printed. Note that name server requests and responses tend to be large and the default _s_n_a_p_l_e_n of 68 bytes may not capture enough of the packet to print. Use the ----ssss flag to increase the snaplen if you need to seriously investigate name server traffic. `----ssss 111122228888' has worked well for me. NNNNFFFFSSSS RRRReeeeqqqquuuueeeessssttttssss aaaannnndddd RRRReeeepppplllliiiieeeessss Sun NFS (Network File System) requests and replies are printed as: _s_r_c._x_i_d > _d_s_t._n_f_s: _l_e_n _o_p _a_r_g_s _s_r_c._n_f_s > _d_s_t._x_i_d: _r_e_p_l_y _s_t_a_t _l_e_n _o_p _r_e_s_u_l_t_s sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165 wrl.nfs > sushi.6709: reply ok 40 readlink "../var" sushi.201b > wrl.nfs: 144 lookup fh 9,74/4096.6878 "xcolors" wrl.nfs > sushi.201b: reply ok 128 lookup fh 9,74/4134.3150 In the first line, host _s_u_s_h_i sends a transaction with id _6_7_0_9 to _w_r_l (note that the number following the src host is a transaction id, _n_o_t the source port). The request was 112 bytes, excluding the UDP and IP headers. The operation was a _r_e_a_d_l_i_n_k (read symbolic link) on file handle (_f_h) 21,24/10.731657119. (If one is lucky, as in this case, the Page 14 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) file handle can be interpreted as a major,minor device number pair, followed by the inode number and generation number.) _W_r_l replies `ok' with the contents of the link. In the third line, _s_u_s_h_i asks _w_r_l to lookup the name `_x_c_o_l_o_r_s' in directory file 9,74/4096.6878. Note that the data printed depends on the operation type. The format is intended to be self explanatory if read in conjunction with an NFS protocol spec. If the -v (verbose) flag is given, additional information is printed. For example: sushi.1372a > wrl.nfs: 148 read fh 21,11/12.195 8192 bytes @ 24576 wrl.nfs > sushi.1372a: reply ok 1472 read REG 100664 ids 417/0 sz 29388 (-v also prints the IP header TTL, ID, and fragmentation fields, which have been omitted from this example.) In the first line, _s_u_s_h_i asks _w_r_l to read 8192 bytes from file 21,11/12.195, at byte offset 24576. _W_r_l replies `ok'; the packet shown on the second line is the first fragment of the reply, and hence is only 1472 bytes long (the other bytes will follow in subsequent fragments, but these fragments do not have NFS or even UDP headers and so might not be printed, depending on the filter expression used). Because the -v flag is given, some of the file attributes (which are returned in addition to the file data) are printed: the file type (``REG'', for regular file), the file mode (in octal), the uid and gid, and the file size. If the -v flag is given more than once, even more details are printed. Note that NFS requests are very large and much of the detail won't be printed unless _s_n_a_p_l_e_n is increased. Try using `----ssss 111199992222' to watch NFS traffic. NFS reply packets do not explicitly identify the RPC operation. Instead, _t_c_p_d_u_m_p keeps track of ``recent'' requests, and matches them to the replies using the transaction ID. If a reply does not closely follow the corresponding request, it might not be parsable. KKKKIIIIPPPP AAAApppppppplllleeeettttaaaallllkkkk ((((DDDDDDDDPPPP iiiinnnn UUUUDDDDPPPP)))) Appletalk DDP packets encapsulated in UDP datagrams are de- encapsulated and dumped as DDP packets (i.e., all the UDP header information is discarded). The file /_e_t_c/_a_t_a_l_k._n_a_m_e_s is used to translate appletalk net and node numbers to Page 15 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) names. Lines in this file have the form _n_u_m_b_e_r _n_a_m_e 1.254 ether 16.1 icsd-net 1.254.110 ace The first two lines give the names of appletalk networks. The third line gives the name of a particular host (a host is distinguished from a net by the 3rd octet in the number - a net number _m_u_s_t have two octets and a host number _m_u_s_t have three octets.) The number and name should be separated by whitespace (blanks or tabs). The /_e_t_c/_a_t_a_l_k._n_a_m_e_s file may contain blank lines or comment lines (lines starting with a `#'). Appletalk addresses are printed in the form _n_e_t._h_o_s_t._p_o_r_t 144.1.209.2 > icsd-net.112.220 office.2 > icsd-net.112.220 jssmag.149.235 > icsd-net.2 (If the /_e_t_c/_a_t_a_l_k._n_a_m_e_s doesn't exist or doesn't contain an entry for some appletalk host/net number, addresses are printed in numeric form.) In the first example, NBP (DDP port 2) on net 144.1 node 209 is sending to whatever is listening on port 220 of net icsd node 112. The second line is the same except the full name of the source node is known (`office'). The third line is a send from port 235 on net jssmag node 149 to broadcast on the icsd-net NBP port (note that the broadcast address (255) is indicated by a net name with no host number - for this reason it's a good idea to keep node names and net names distinct in /etc/atalk.names). NBP (name binding protocol) and ATP (Appletalk transaction protocol) packets have their contents interpreted. Other protocols just dump the protocol name (or number if no name is registered for the protocol) and packet size. NNNNBBBBPPPP ppppaaaacccckkkkeeeettttssss are formatted like the following examples: icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*" jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250 techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186 The first line is a name lookup request for laserwriters sent by net icsd host 112 and broadcast on net jssmag. The nbp id for the lookup is 190. The second line shows a reply for this request (note that it has the same id) from host jssmag.209 saying that it has a laserwriter resource named "RM1140" registered on port 250. The third line is another reply to the same request saying host techpit has Page 16 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) laserwriter "techpit" registered on port 186. AAAATTTTPPPP ppppaaaacccckkkkeeeetttt formatting is demonstrated by the following example: jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000 jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001 jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002 Jssmag.209 initiates transaction id 12266 with host helios by requesting up to 8 packets (the `<0-7>'). The hex number at the end of the line is the value of the `userdata' field in the request. Helios responds with 8 512-byte packets. The `:digit' following the transaction id gives the packet sequence number in the transaction and the number in parens is the amount of data in the packet, excluding the atp header. The `*' on packet 7 indicates that the EOM bit was set. Jssmag.209 then requests that packets 3 & 5 be retransmitted. Helios resends them then jssmag.209 releases the transaction. Finally, jssmag.209 initiates the next request. The `*' on the request indicates that XO (`exactly once') was _n_o_t set. IIIIPPPP FFFFrrrraaaaggggmmmmeeeennnnttttaaaattttiiiioooonnnn Fragmented Internet datagrams are printed as ((((ffffrrrraaaagggg _i_d::::_s_i_z_e@@@@_o_f_f_s_e_t++++)))) ((((ffffrrrraaaagggg _i_d::::_s_i_z_e@@@@_o_f_f_s_e_t)))) (The first form indicates there are more fragments. The second indicates this is the last fragment.) _I_d is the fragment id. _S_i_z_e is the fragment size (in bytes) excluding the IP header. _O_f_f_s_e_t is this fragment's offset (in bytes) in the original datagram. The fragment information is output for each fragment. The first fragment contains the higher level protocol header and Page 17 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) the frag info is printed after the protocol info. Fragments after the first contain no higher level protocol header and the frag info is printed after the source and destination addresses. For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa over a CSNET connection that doesn't appear to handle 576 byte datagrams: arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+) arizona > rtsg: (frag 595a:204@328) rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560 There are a couple of things to note here: First, addresses in the 2nd line don't include port numbers. This is because the TCP protocol information is all in the first fragment and we have no idea what the port or sequence numbers are when we print the later fragments. Second, the tcp sequence information in the first line is printed as if there were 308 bytes of user data when, in fact, there are 512 bytes (308 in the first frag and 204 in the second). If you are looking for holes in the sequence space or trying to match up acks with packets, this can fool you. A packet with the IP _d_o_n'_t _f_r_a_g_m_e_n_t flag is marked with a trailing ((((DDDDFFFF)))). TTTTiiiimmmmeeeessssttttaaaammmmppppssss By default, all output lines are preceded by a timestamp. The timestamp is the current clock time in the form _h_h:_m_m:_s_s._f_r_a_c and is as accurate as the kernel's clock. The timestamp reflects the time the kernel first saw the packet. No attempt is made to account for the time lag between when the ethernet interface removed the packet from the wire and when the kernel serviced the `new packet' interrupt. SSSSEEEEEEEE AAAALLLLSSSSOOOO traffic(1C), nit(4P), bpf(4), pcap(3) AAAAUUUUTTTTHHHHOOOORRRRSSSS Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. The current version is available via anonymous ftp: _f_t_p://_f_t_p._e_e._l_b_l._g_o_v/_t_c_p_d_u_m_p._t_a_r._Z BBBBUUUUGGGGSSSS Please send bug reports to tcpdump@ee.lbl.gov. NIT doesn't let you watch your own outbound traffic, BPF will. We recommend that you use the latter. Page 18 (printed 2/6/99) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((33330000 JJJJuuuunnnneeee 1111999999997777)))) TTTTCCCCPPPPDDDDUUUUMMMMPPPP((((1111)))) Some attempt should be made to reassemble IP fragments or, at least to compute the right length for the higher level protocol. Name server inverse queries are not dumped correctly: The (empty) question section is printed rather than real query in the answer section. Some believe that inverse queries are themselves a bug and prefer to fix the program generating them rather than tcpdump. Apple Ethertalk DDP packets could be dumped as easily as KIP DDP packets but aren't. Even if we were inclined to do anything to promote the use of Ethertalk (we aren't), LBL doesn't allow Ethertalk on any of its networks so we'd would have no way of testing this code. A packet trace that crosses a daylight savings time change will give skewed time stamps (the time change is ignored). Filters expressions that manipulate FDDI headers assume that all FDDI packets are encapsulated Ethernet packets. This is true for IP, ARP, and DECNET Phase IV, but is not true for protocols such as ISO CLNS. Therefore, the filter may inadvertently accept certain packets that do not properly match the filter expression. Page 19 (printed 2/6/99)